repack: the container is verified against the GGUF it came from, under the name that says so (refs #1109) - #1234

…a foreign-order directory is refused offline (Fixes #1110) (#1275)

* npu: check_q4nx_dir --against measures the q4_1 TILE ORDER, so a foreign-order dir is refused offline

engine#1110's surviving hole: the repack measures the tile order (#1169/#1234) and the plan
loader refuses a declared order it does not implement (#1130), but a directory that was never
repacked here -- imported from a foreign converter, downloaded, copied off a board -- has no
stamp and no plan, and every metadata check passes: the two orders share the chunk kind, the
byte count and the tensor names.  Only the weights can say which order the bytes are in.

--against already decoded the first Q8 tile both ways against the source GGUF; it now does the
same for q4_1 over all three orders this repo can name -- ours (npu/q4nx.cpp's), flm signed,
flm unsigned -- with tools/q4nx_diff.py's own decoders imported rather than re-implemented, and
refuses a container whose winner is not ours: tensor name, all three correlations, and the
closest foreign reading in the message.  Accepted when ours >= 0.99 and ours - best_other >=
0.5, both measured: a container packed from Q4_K_M reads +1.0000, one packed from BF16 +0.996,
every foreign order |corr| < 0.05.  The metadata-only path still imports no numpy and no gguf.

Tests: tests/check_q4nx_tile_order_test.py builds the case the issue describes -- one known
32x256 weight encoded as a single q4_1 tile in the engine's order and again in the foreign one,
each encoder round-tripping through its own decoder first (4.17e-03) while the same bytes read
as 'ours' are 1.31e-01 wrong -- then requires pass/refuse, the refusal to name the tensor, the
foreign reading to be identified, and the verdict to survive a rename to another tensor.

* npu: decide the q4_1 order on the margin, not a 0.99 proximity cut, and make the self-test follow the message

Review blockers, both real.

1. `--self-test` exited rc 1 at every commit of this branch: the summary line was reworded
   ("no Q8 or q4_1 tile was decoded ...") and the assertion at the old line 522 still looked for
   "no Q8 tile was decoded".  My own run had printed that failure and I quoted "self-test ok" from
   its tail without reading its exit code -- the exact claim-before-check mistake this lane keeps
   writing down.  Fixed, and the self-test now also covers the q4_1 selector and the sampler
   (pure python: a 5120-B I8 tensor is q4_1, 4736/8704 are not; spread() reaches both ends).

2. `ours >= 0.99` was a proximity cut on quantization error, and it refused the PR's own
   non-regression row: on a full sweep of the published FastFlowLM Qwen3-0.6B-NPU2 directory the
   outlier-heavy `layers.2.mlp.down_proj` reads corr +0.9890 (rel-rms 0.1477) with a margin of
   ~0.95 over every foreign reading -- unmistakably the engine's order -- yet the check refused it
   and then said "NOT in the order, best is ours", which contradicts itself.

   The order is now decided on the MARGIN -- ours wins and beats the runner-up by >= 0.5 -- with a
   0.9 floor that only rules out "no reading matches at all".  Measured: correct containers lead by
   >= 0.95, foreign ones by <= 0.05 (the d1d5232 container: ours +0.0477 vs flm-unsigned +0.9961).
   The refusal now says which of the three things happened instead of one message for all:
   no reading matches (wrong GGUF or an unnameable order), a foreign order it can name, or an
   ambiguous margin (a partly foreign container).

Also, per the review's non-blocking note: samples are spread evenly across the table instead of the
first N in table order, so a foreign order that varies tensor to tensor is not missed by sampling one
layer.

Tests: tests/check_q4nx_tile_order_test.py grows to 14 checks.  The new ones are the regression the
floor caused (a correct container at corr +0.9827 must pass -- inside the band the old floor refused)
and the wrong-source case (must say "no reading of these tiles matches", never claim a foreign order
it cannot identify).  Negative control: restoring `ours >= 0.99` makes exactly the new regression
check fail and nothing else, so the test bites on this bug and not on a coincidence.

---------

Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>